Business Analyst Community & Resources | Modern Analyst

Negotiation skills – are they really for Business Analysts?

David Wright — Fri, 13 Sep 2013 01:10:00 GMT

I keep seeing in BA skill descriptions or in specific articles that ‘negotiation skills’ are a necessity for Business Analysts. I just don’t see it myself. Negotiation is a difficult activity for many people, and I see this trend as an attempt to offload negotiation to other people… like Business Analysts.

Why do I feel this way? As an activity, ‘negotiation’ is when people with differing needs but overlaps in other areas (like sharing resources and money) need to reach an agreement that helps them in some way while giving up something in order get that agreement. In business, and especially IT, the need to reach such agreements occurs all the time. It often looks like this: a business unit has objectives to reach and a certain budget, and they need enhanced/new systems to reach the objectives. IT has the resources and tools to do the work. Both have useful but always limited assets.

In this situation, Business Analysts have no assets to negotiate with, what BAs bring to the table are analysis skills. It is the business and IT that need to negotiate an agreement about money to be spent on IT activities, including what the business gets for their money, and when they get it by. Business Analysts bring enough detail and clarity to these points so that both parties are happy; the business is able to define what they need, and IT is able to say what it will take and how long it will take.

The nature of limited resources and increasing time-to market pressures will almost always result in the business wanting more they can afford and/or want it sooner than it can be delivered. This is usually where ‘negotiation’ is said to occur by Business Analysts, but it only happens if one of the parties offloads their participation to the BA, who is told what to offer but has no real authority to bargain.

The better situation is where both sides remain engaged and the BA uses techniques like prioritization to help reach an agreement on acceptable deliverable for a feasible price and time. All through this, the BA is a ‘facilitator’, not a ‘negotiator’. Smoothing the way to agreement makes life is easier for the real negotiators; if we BAs do our jobs well enough, the involved parties will never even know or feel that they were negotiating!

Agile is an attractive word

David Wright — Mon, 29 Apr 2013 17:46:00 GMT

Agile is an attractive word. It means swiftness with discipline, with an emphasis on alertness to change in one’s external surroundings and quickly responding to change as needed.

The word I want to focus on from above is "external". A prime example of the difference between internal (controlled) and external (un-controlled) is an operating enterprise: business company, non-profit group and the like. The interesting problem for most enterprises is how effectively they control their own operations. The boundary between internal and external can become nebulous if control is lacking in parts of an enterprise. Control sounds like a bad word. It implies top-down definition of all aspects of enterprise operations. This can be true, but control can also include delegation of authority, with expectation of results without definition of methods used. Control is maintained, but authority is distributed. This is the sphere of business management practices, defined and changing and transforming from Henry Ford to Jack Welch. It is not easy, and many others have and will address it better than I, so I will reference them as need be.

The topic of interest here is the boundary between internal and external, controlled and uncontrolled, event and response… but not between knowable and unknowable. An enterprise needs to know what is happening around it in order to focus its operations on knowing what events are important, events that it needs to respond to. For these events, an enterprise defines processes/procedures to execute when triggered by events, to provide the desired results in response to the events; successful enterprises include those that recognize that the nature of events and corresponding processes change over time, sometimes very quickly. So, at any one point in time, an enterprise needs to be in control of its processes, but that control can’t stifle the need to change as fast as the world around it changes. Further, this rapid change needs to be accomplished without disrupting on-going operations.

What we are discussing here is Controlled Agility; the ability of an enterprise to respond swiftly to changes in its surroundings without losing its internal cohesion. The basis for controlled agility in an enterprise includes understanding that: - an enterprise runs on its processes, not its org chart - processes are composed of distinct activities and decisions - processes run on information, gathered and stored and used - processes are guided by business rules, especially when decisions need to be made. With this basis, an enterprise is well-positioned to be Agile without losing Control. It all comes down to understanding Change. Change comes in many degrees of impact to an enterprise. Consider workflow, which is based on process with roles and authority levels defined. If all loan applications over $100,000- go to Fred to be underwritten, the workflow will change temporarily when Fred goes on vacation. Those loan applications have to go to someone else until Fred gets back. This kind of change can happen frequently, but more importantly, it is a kind of change the enterprise knows can happen.

Frequent known changes are the heart of controlled agility. This is the kind of change an enterprise must be able to do, without changing itself, as part of operations. It should not need a project, especially an IT project, to make the change. Temporarily changing workflow might be considered a simple example, but it is actually an example of an overall type of change that can occur frequently, and that is business rule change. Business Rules are so embedded in how an enterprise works, it is actually a new and revealing approach to call them out separately. In a lender enterprise, it is likely a fact that “Customers may apply for Loans”, but “Customers may apply for Loans, only if they are 18 years old or older” is a Business Rule; it constrains an aspect of enterprise operations and, as said above, rules change (next year it could be 19 years). An enterprise that knows the facts and rules of their operations is well positioned to change rules as quickly as needed. However, rule changes still need to be controlled to avoid using incorrect rules to the detriment of the enterprise. Still, these changes should not require a project to change the structure of the operation and, again, not need an IT project. A major use of rules is to support making decisions. Loan underwriting across many financial lending/leasing enterprises is heavily rule-driven, the information about a customer and the loan product being used to decide to lend or not. These can be complex rules, or simply that the enterprise does not lend to anyone with a Credit Score below a stated value; and again, the rules will be changed over time as a lender tunes its underwriting, or is willing to take on more risk, etc..

Decisions also play a role in defining what processes/activities are used to respond to events. We all know of BPM diagrams with boxes for activities, diamonds for decision points, and arrowed lines connecting them all. A process may be composed of 20 possible activities, but less than 20 might be used in response to any one event because of decisions based on rules. What can change for a process? The number of processes in an enterprise, once all are defined, is relatively stable over time; new processes usually mean the enterprise has expanded its products/services to areas which need their own processes. Within a process, however, the exact activities that are carried out may change, or be re-ordered, or even be retired. It is the ability to change processes as quickly as possible, again without a project, that marks an enterprise as Agile. Changes in decisions and rules used in processes are the most frequent changes an Enterprise must do. Changes to the activities in a process change less frequently than decisions/rules, but often enough the agile enterprise needs to it as part of its operations. Are there aspects of an enterprise that are more stable? And are types of changes to them not necessarily known or predictable? This is a loaded question, because the answer is information or specific data used by an enterprise. Once all the information needs are known for an enterprise, these are very stable over time. The need to change information needs is similar to the need to add more processes; it happens when (as above) the enterprise is expanding into new products or services different from current products/services. To be more precise, information needs may change as the enterprise expands, but they may not as well; data requirements have been shown to be the most stable aspect of an enterprise.

So we have two ends of the change pendulum: from frequent and known, to rare and unknown. As said earlier, frequent known changes are the heart of controlled agility.

Follow-up to “So, you’re buying a package? Don’t forget your business requirements…” Don’t over-analyze!

David Wright — Sat, 09 Feb 2013 02:47:00 GMT

For those of you who do define requirements for their software development projects, but are new to buying packages, a cautionary warning; they are not the same thing. Consider the following “the system shall” requirement statements.

1) The system shall determine if a person ordering pizza is a current customer.

2) The system shall determine if a person ordering pizza is a current customer, only if the person is phoning to place an order.

3) The system shall determine if a person ordering pizza by phone is a current customer using the person’s name and phone number.

Each requirement is at a certain level, increasing in detail from (1) to (2), and from (2) to (3).

- Requirement (1) is at high-level, stating that the system shall do something with certain information.

- Requirement (2) is more detailed, stating that the system shall do something with certain information, in a certain situation.

- Requirement (3) is fully detailed, stating that the system shall do something with certain information, in a certain situation, according to certain rules.

Requirement (3) is what you need to provide to designers/developers to use in new software development. However, this not what you need to provide to vendors when you send them an RFP; in fact, this level of detail can be over-kill analysis and can restrict the number of vendors who could meet your needs. By being very specific about rules and restrictions, you may eliminate a vendor who has a different and possibly better approach to meeting the business need, e.g. a better way to determine who is a current customer.

So what level of detail do you need? High level requirements like (1) can be useful at the start of a project, to describe scope and support planning; this level can also be used in a Request for Information (RFI) sent to vendors, just to get an initial view of what the marketplace looks like.

When you get to an RFP, you need more detail to differentiate vendors better, and Requirement (2) is an example of this level, which I call mid-level or standard-level of detail for requirements. At this level, you can see the difference between vendors in meeting your requirements, enough to evaluate their product and decide which one will serve you best.

So I now have two recommendations for organizations looking to buy a package:

- Don’t forget your business requirements…

- … but don’t over-analyze your needs, so you can best evaluate those packages.

“Why do I need Requirements? I’m buying a Package!”

David Wright — Mon, 31 Dec 2012 02:59:00 GMT

In the wide world of information systems, development of new software receives the most attention from industry writers. Whether it is traditional magazine articles and books, or blog posts, or discussions in groups on LinkedIn and other sites, it is all about “green field” development.

However, when one considers the wider view of organizations concerning information systems, it is common that new software development is not always the primary means of implementing new systems. Organizations do need software for many different functions and data, but a lot of those are common; organizations that realize this do not develop their own software for common needs, they buy it. It actually started a few decades ago with functions like general ledger accounting and human resources, then it moved into more specific domains like insurance or banking, and on into cross-domain ERP packages popularized by major vendors.

When organizations first started to buy more than build, they were often delighted by the time savings: “I can have it now? And not wait 2 years for it to be developed in-house? Where do I sign?” What many organizations did not realize, and their internal IT people probably didn't see either (at first), was that it was only the pure development and system testing activities that were being saved. There was still the need to determine what the package was actually going to do. While software apps provide many common and standard functions, which ones are implemented, and how they are configured still vary significantly based on an organization’s own needs. Ahead of that, the decision has to be made concerning which package to buy in the first place.

This is where business requirements come in. Again, the focus and discussions about requirements these days is primarily about their role in new software development, such that some organizations forget or discount the need for requirements when buying packages… This is a recipe for disaster.

It is true that companies buy things all the time, and often use a standard Request for Proposal (RFP) process. A common process is a good thing, and proposals for quantifiable products such as hardware or components can be straightforward. An RFP for software, however, is specifying an intangible thing that has to perform a function in a specific way. That means defining complete and correct business requirements.

A web search on RFPs or package implementation failures will quickly identify a primary cause; “Failure to clearly define the business requirements for the project”.

(see http://www.orionsecuritysolutions.com/the-o/item/188-request-for-proposal-mistakes).

Even the (in)famous lawsuit between Waste Management Inc. and SAP concerning a failed project included a claim by SAP of Waste Management "failing to timely and accurately define its business requirements" as a contributing reason for the failure.

(see http://www.cio.com/article/486284/10_Famous_ERP_Disasters_Dustups_and_Disappointments).

(For even more on the importance of requirements, see the Business Analysis Benchmark Study from IAG Consulting, see http://www.iag.biz/resources/library/business-analysis-benchmark.html )

So, an organization cannot skip over or pay lip service to business requirements definition in software package projects. Done properly, good business requirements can be used to directly fill the part of an RFP that scares most people: the functionality and data that a package has to meet to be considered for purchase.

When first putting together a list of candidate packages, there may be a lot of vendors who claim to meet your needs based on a summarized description of their products; sending vendors an RFP containing good business requirements will quickly weed out the ones who don’t measure up. Many times, (good) vendors react to this kind of RFP by declining to respond when they see that their product really does not meet the business requirements; this saves both parties time and effort on a deal that would never have gone through.

This will normally lead to a short list of vendors who have a product that could meet the requirements. Getting to one vendor usually involves product demonstrations, on-site trials and other means of evaluation. Of course, other requirements need to be met as well, perhaps technical requirements the software has to meet to run in the desired environment (although hosted and other “cloud” options are changing this). The best scenario is to have two or three vendors whose products will meet the requirements, after which the remaining negotiations can be about getting a good price … all because of having defined the business requirements.

And last but certainly not least, having the business requirements eases the implementation of a package. In decades past, buying a package meant buying code; if alterations to the package were needed, that meant changing code, and getting it to work. This was often difficult and would commonly void any agreement with the vendor to support the package and provide updates.

These days, good packages are built to be configurable. A vendor will often have consultants who can configure the package; and what do those consultants need as input? Your business requirements.

If by chance and very good luck, the project has reached this point without having defined the business requirements, they will have to be defined now if the package is ever going to work properly; and there is a very likely possibility that when the requirements are finally documented, it is clear that the wrong package was purchased. That’s when stories about project failures turn up in industry magazines and sites, and even the regular media if the failure is colossal enough.

So, you’re buying a package? Don’t forget your business requirements…

Getting to FRs, part 3 - it's the process, dammit

David Wright — Fri, 02 Sep 2011 03:06:00 GMT

People expect a lot from their information systems, but it usually it comes down to one thing: the system has to do stuff. When you talk about systems, the verbs are active: the system is running, it is executing a function, the system is responding, ....

And what do you want it to do? You want it to do as much of your business process as it can, and then keep adding to it over time. So, you have to know your process, define it down to the steps and sub-steps that get you from input to desired output, from trigger to goal. And not just what you do now, you have to define the future state you want your process to be in, and with flexibility to accept change as well.... because each step in that future process is a Functional Requirement, "the system must have the ability to do this...and ... and this." ....

And if you focus on identifying a candidate process, like Sell a Pizza, you can define all the steps necessary for a major process in 5 to 10 days.

Hah, you say... so I must tell you It takes focus and commitment. Give me 5 to 7 business people --- some managers, some staff who work the process --- six hours a day in facilitated sessions (with me plus a real-time documenter) and you will have all the functional requirements you need in days, not weeks or months. And it is something that your people can learn to do as well.

I don't want to use Modern Analyst to make a sales pitch; I just want people to know that getting to Functional Requirements does not have to be a long, drawn-out effort.

Comments? Thoughts? Counter-arguments?

Getting to FRs, part 2 - Scope is not just mouth wash...

David Wright — Thu, 25 Aug 2011 01:52:00 GMT

Let me reprise the words of Mr. Brooks ...

“… the hardest single part of software development [remains] deciding precisely what to build."

Fred Brooks

Author of the 1986 paper "No Silver Bullet”

The unspoken corollary to this is you have to be sure you don't build the wrong system. Knowing what and what not to build is a matter of defining Scope.

I will not claim this is a new revelation; how would we have everyones favorite problem, scope creep, without trying to define scope in the first place?

A number of scope definition methods exist; I started with the side-by-side list. One list is things that are in scope, beside it a comparable list of things that are out of scope. This is good, a good start for discussion, but you then have to get specific about what the system will and will not do. For that, the business has to select one of its processes as the object of the system's automation.

Using computers to automate a process sounds like data processing from the 60s or 70s, but it is still essentially true. Of course you don't just automate what people are doing today, Structured Analysis and Design taught us that a long time ago (although a bit heavily). Businesses have recognized that good process is critical, and so are the systems that support them.

So when a project starts, look for the main business process that will be impacted. An example I and my compatriots use is Ordering A Pizza, because almost everyone we work with has ordered a pizza.

Selecting a process is in fact the first act of defining Scope, because all other processes are now out of scope. In our example, an out of scope process can be Buy Pizza Ingredients.

If the project impacts more than one process, it is best to address them as separate efforts while determining any links between them. So not only is scope defined, you have already divided a large project into manageable pieces. This also addresses those concerns about doing all the requirements up front for a large project; working on one process means you can define all it's functional requirements in 5 to 10 days.

Yes, 5 to 10 days... More on how to do that next time.

Getting to Functional Requirements, part 1 - the never-ending open-ended question...

David Wright — Tue, 16 Aug 2011 15:01:00 GMT

Back to the nasty question - what sort of Information System shall will we build?

"What sort of system do you want?"
"hmmm, one that processes all our customer orders, I think. What do you think, George?"
"Well Fred, I suppose so, but I know it has to be fast, and run 24/7."
"OK.........(???)"

We already know the problem with asking people what they want, but it is even worse than you think, because it's an open-ended question; and the problem with open-ended requirements questions is determining when the question has been fully answered. How do you know you have all the requirements? Well, you don't.

Wait, it gets worse! How do you know if the requirements you did get are relevant? If any of them are duplicates? If any of them contradict other requirements? Again, you don't.

So you need a different question. When you ask people what they want, you can get blank stares in return... but, if you ask people what they do, you will get all their knowledge and expertise in return; and that is where the requirements will come from... look for part 2 on getting to FRs soon.

The "R" Word

David Wright — Wed, 10 Aug 2011 04:11:00 GMT

Software is a uniquely new invention, different than anything else we humans have come up with in the past. ...

"The software-controlled electronic information system is fundamentally different from physical labor-saving devices such as the cotton gin, the locomotive, or the telephone. Rather than extend the ability of hand motion, leg motion, or the ability to hear and speak across distances, ITsystems extend the capabilities of the mind—to think, to organize and disseminate information, to create."

David R. Brousell
Editor-in-Chief
Managing Automation Magazine
New York, October 2001

To me, this means that it is inherently difficult to know what some software should do, because it can do whatever you need it to. ... but what do you need it to do?

That is the question, isn't it?

“… the hardest single part of software development [remains] deciding precisely what to build."

Fred Brooks
Author of the 1986 paper "No Silver Bullet”

I keep saying "needs", because the term that is actually used in software development is a lightning rod for debates.If you have been kind enough to read this far, you knowI am talking about "Requirements".

If you are going stick with me going forward, you will see that I am a firm believer that efficient and effective requirements discovery is a key contributor to successful deliveryof good software. It is not the only contributor to success, but it is part of the mix. I do know that bad or non-existent requirements are a pretty good predictor of a failureto deliver good software.

The real issue of interest is what is a requirement. The answer is multi-faceted and of course still a subject of debate, but that keeps things interesting and worth writing about.

Information Systems Users don't know what they want... So, don't ask them what they want...

David Wright — Sun, 07 Aug 2011 03:12:00 GMT

Information Systems Users don't know what they want... So, don't ask them what they want: and definitely don't write some software and then say "how's this look?".

On the other hand, don't have someone spend weeks talking to various people about what they want ( and not get to talk to other people ), write it all down and deliver a document, saying "build this"... and then spend months building "this" and then say "here you go".

But, something must be done; start with a change of focus - Information Systems should not do what users want, Information Systems should do what an organization needs to be successful.Isn't that the same thing?

It should be, but users are people and one person seldom wants what other people want; and people are notorious for wanting one thing now, and something else next month... or even tomorrow.

So change focus - from people to organization, and from wants to needs.

The User Myth

Please keep in mind that the scope of my opinion is Information Systems, mainly the type of systems that people are paid to use, people otherwise known as 'employees'.

A lot of systems and software are not in this scope. For example, what I have written here was first drafted using a notes app on my mobile device; that is a whole different thing, one I always want to explore... But when I go out to work for clients, it is almost always for Information Systems: "we need a new system to process more orders" ... "our loan approval system has to be expanded" ... "the State is changing the rules for UI eligibility" ...

So let's address the User Myth.

First, I am not the first person to note that the only other people who are referred to as "users" are drug addicts, but it seems to be a term we are stuck with. Seriously, when I drive, am I a car user?

Now consider those employees I mentioned up front. When they are hired, they always get trained on the existing systems they need to do their work. Given the multiple-year lifespan of a typical information system, and the usual level of turnover in a department/function of an organization, a lot of people will use a system over time. Very few of this number will have been there for the introduction of the system, and usually none of those people will still be around when the system is retired and replaced with something else.

And yet we are supposed to assume the group of people using a system at it's retirement are automatically the experts who should be asked what they want in a new system? Think about this for a moment or two; that should be all the time you need to conclude "well, no".

That's because users come and go, but systems (seemingly) go on forever.

The current group of employees who are expected to use a new system are indeed important stakeholders and participants in creating that system, but they are not the only ones. (And still, some of them could be gone before the system is finished.)

So change your focus to the needs of the organization; stay tuned for my approach on doing just that.

Separating Requirements Elicitation from Business Analysis

David Wright — Thu, 28 Apr 2011 19:12:00 GMT

What do you need the most when eliciting Requirements? Face-time with Subject Matter Experts and their Managers. As a Business Analyst employed in a typical organization, what is the thing you get the least of? Face-time with Subject Matter Experts and their Managers. Who will Subject Matter Experts and Managers make time to see? Outside Consultants.

Such is the way of the world, at least the one I have worked in for 30 years. Full disclosure: for about 20 of those years I was an employee Business Analyst. I am now an outside Consultant working in Requirements Elicitation, Analysis and Documentation. I have spent more direct time with SMEs and Senior Managers in the last five years than I probably got in those 20 years. Why? Because I have usually been brought in to work an important project, and I am a direct cost to the organization.

If you the reader are an employee working on projects, and not limited to Business Analysts, you know this true. Is it fair to you? Not really, but having been on both sides of this situation, I don’t see it changing anytime soon.

So rather than complain about it, how can you make this work for you? (And yes, what I will suggest should mean more work for me, but hear me out…)

Name one good thing about Consultants: they bring a fresh viewpoint, and they should bring better practices to deliver what they have been hired for.

Name one bad thing about Consultants (or least what many people I know do think): they leave when they are done, leaving it up to those involved employees to carry on what they probably started in the first place, and see it through to the end.

So, please read the first paragraph again… It does not mention all the other things Business Analysts do for their organizations. The role varies from place to place, but it usually does involve more than getting those pesky requirements. My own extra-speciality was project initiation, scoping, doing cost-benefit analyses, and a little Project Management on the side when pro PMs were not available. My experience over the years is that it is possible for an employee BA to get Senior Managers and Project Stakeholders in a room long enough to bash out a project charter, with goals and expected benefits; that is when these people are most engaged, up front when the idea is fresh and the expectation of good results is the highest. It is later on when you need some serious time to elicit requirements that the reticence to show up starts.

On the other hand, many BA’s participate in downstream activities, like testing, user documentation and training. I have actually had some vigorous discussions in the past with people who say that you aren’t a really a BA unless you do those things. I don’t happen to agree, but the fact that many BA’s do it, and do it well, is current reality.

So, you can probably see where I am going here. Being a BA can involve you from start to finish, but the key thing that makes all of it work, getting those requirements, is the hardest thing for a BA to get done, and done correctly; and boy, do you hear about it if the requirements turn out to be incomplete or incorrect. What’s a BA to do?

Separate requirements elicitation out from the all the rest of the work, and bring in an expert (which is how the business sees consultants) to nail down that important piece. Using good practices and standard deliverables, 5 to 10 days is all that is needed to get it done for a medium size project. That means those SMEs/Managers in a room, together, for those days in facilitated requirements discovery sessions. You get the requirements you need, and actually get them a lot faster than if you tried to get time with everyone in separate meetings, try to get it all down in one deliverable, get everybody to review it and approve it. I’ve been there, you’ve been there, and it can take 5 to 10 weeks, if not longer.

So yes, I am selling myself, and the people I work with, as a solution; there have been many buyers so far.

The smartest customers have taken it one step farther. Once we have demonstrated success, the next step they take is to adopt our practices and train their own BA’s; and, of course, we help them do that as well. The most common approach is to train a few people to be the new internal consultants, and often that role (such as “requirements facilitator”) lives on as support to BA’s on all projects. All it takes is a few early successes and those hard-to-get business people (the start of this whole discourse) will be more than happy to be part of Requirements Elicitation.

So, divide and conquer, then reunite for long term success. That’s win-win-win for everyone.

Who owns a Project? and, who is IT’s Customer?

David Wright — Thu, 12 Mar 2009 17:49:00 GMT

Who owns a project?

“You pay for it, it’s yours.”

I am sure I am quoting (or misquoting) someone here, but you get the idea. For an IT project of any size or worth, someone senior enough to be an effective sponsor is usually desired, along with the budget to ‘pay’ for it. I put ‘pay’ in quotes because all the dollars spent on a project aren’t coming personally from a Sponsor; they are the guardian of the funds allocated to them in a budgeting process. I make this distinction because some companies operate by having IT treat other areas as customers, which I think is a mistake. The only real customers are those who pay for your company’s goods or services; they in fact are paying for your projects, along with investors and other sources of funds, Inside the organization boundary, the customer/supplier is not a good model. It can lead to uncontrolled competition for resources and business people going outside for IT services if they decide they don’t like IT anymore.

The real model for project and business success is the team, and good companies know that. From the sponsor down to the junior ranks, all must work together to deliver the results. Sure, there are hierarchies, chains of command (and performance reviews!), but they exist to organize and support the team.

The worse case I have seen of the Customer model was the use of internal budgets like real money. In one of my previous jobs, one business unit had built a good system, and so a similar unit was interested in re-using it. The original business unit wanted a budget payment before releasing the system (I call this funny money), to offset the development cost and improve the units internal bottom-line, with direct impact on management bonuses. The second unit balked at the ‘cost’ and so went out and bought a package that ‘cost less’, spending real money when re-use at no real cost was possible. I still shake my head when I think of this.

I have also finally been boning up on ITIL, courtesy of some great posts by Terry Longo. What scared me right away was its focus on Services as the basis for management of IT assets and other resources. It made me think that someone had taken the very good idea of software services (SOA) and applied it to all of IT. What scared me worse is I saw the appeal of doing it this way, and will be reading more to see if it really bows down to the internal customer model.

I would say at this point that a Services approach can work if the users of IT services (don’t call them Customers!) and IT itself agree on a few things.

… a Services model is used to effectively manage IT for the whole organization. It does not define an internal marketplace for IT services.

…users can’t outbid other users for services; allocating scarce resources has to be based on overall organization strategies and plans, not the size of department budgets

…IT manages external resources as well internal; no outside shopping by users

…and don’t call the users Customers!!!

Memories of IT

David Wright — Fri, 20 Jun 2008 02:50:00 GMT

I am now lucky enough to be working at a consulting company with a great group of experienced people, and we do share some great "war stories", and it made me think that I do have my share of experiences that, if written down, some small number of people may find interesting. Seems to me a blog is great for that.

I would call this memories rather than a "memoir"; the latter would imply I have spent time researching myself and might, for example, be able to name all the people I went to school with or have worked with over the last 3 decades; not gonna happen. People who write Memoirs were also usually prescient enough to keep a diary or journal since a young age, but not I.

But, I don't think anybody will be checking my facts or lack of them; and as a blog, any reader of a certain age who wants to chime in is most welcome.

Where does it start? Spring 1972, 10th Grade ( or "Grade 10" as we called it in Canada), looking at optional courses for 11th grade in the fall, and my eyes come upon "Computer Science"; sounds interesting, what the heck...

Next time: Highschool computer science...

Cascade - that's all 13 Principles of mine: do you have any? win a free copy of my book.

David Wright — Wed, 18 Jun 2008 03:27:00 GMT

Thirteen is all you need, at least in this point in time. I may add to them as time goes by, but I would also like to hear from readers if they have any suggestions or thoughts or their very own principles for IT Projects success. Pleae offer them and maybe we can get them into the second edition of the book...which you all remember is available at http://www.lulu.com/content/2088656 .

In fact, if (and its a big if) I get a number of suggestions, I will judge which one to be the 'best' of the bunch; winner gets a free copy of the book.

And to get things going, a free copy of the book also goes to the first person to submit a suggestion, so be quick!

David W. Wright

Cascade Day 15 - Principle #13: Use Architecture to Manage and Integrate the Deliverables

David Wright — Sat, 14 Jun 2008 03:23:00 GMT

13. Given many medium to small software Deliverables, use Architecture to manage and integrate the Deliverables into a complete system.

This is a more specific statement of Principle #3; in Cascade, an Information System Architecture is used to integrate the two week deliverables, until a complete deliverable (component, sub-system) is assembled.

In parallel, a release schedule is a great approach to support delivery. Gather the usable deliverables into timed releases that go into production together. As per Principle #11, a Release each quarter is recommended. The business receives what they are paying for often enough to be of value, but not often enough such that assimilation of change is so frequent it causes chaos.

Cascade Day 14 - Principle #12: Parcel work into two-week periods

David Wright — Tue, 10 Jun 2008 03:16:00 GMT

12. Within the three month phase, parcel work into two-week periods; analyze for 2 weeks, then design and develop for 2 weeks (two developers), and then test for 2 weeks. When the first 2 weeks of analysis is done, start the next two weeks of analysis in parallel to the design/development; carry on in cascading 2 week periods until the entire project scope has been addressed.

OK, a 64 word-long paragraph is pushing the boundary of a ‘Principle’, but this point is the basic building block of Cascade. Are two week periods too aggressive? I think not, based on experience. I find developers and a tester like to work in such quick bursts, as delivering more results faster makes anyone feel more productive and accomplished, and illustrates quickly what works and doesn’t work. However, small bits delivered quickly need to be integrated into an overall solution, which leads to Principle #13.

Cascade Day 13 - Principle #11: Partition large projects into 3 month phases, that is the longest period you can plan for without the chance of significant change

David Wright — Fri, 06 Jun 2008 02:59:00 GMT

#11. Partition large projects into 3 month phases, that is the longest period you can plan for without the chance of significant change to priorities, resourcing, etc.

I was lucky to learn this early in the 90's as Project Management was getting a higher profile, accompanied by the increased use of Microsoft Project. Other PM tools were in use, but usually in limited numbers; MS Project, on the other hand, was readily available and budding Project Managers thought they could now plan the whole world for months or years in advance. What actually happened, however, was constant re-planning as the reality of business change and resource turnover always took their toll. As Napoleon said, "A plan is only good until the battle is joined." After that, one must adapt to the changes that will always come.

My own experience was on a large project that was broken into a dozen pieces, which were planned separately to a target 18 months away, at which point I was asked to integrate them into one plan while resolving resource conflicts. First thing we found was that MS Project of that time crashed when you reached around a thousand tasks.

So, it was around then that some IBM PM consultants were brought on to sort out this mess, and where I first heard the above principle. Yes, you need a plan to get started and to control a project over time. You can even sketch out a plan out over many months to see and communicate the big picture; but, do not commit to any target date over 3 months away, odds are you will miss it. This also means you should do the detailed planning only to the next target date, meaning the full WBS and resource assignment. (At the other end of the detail level, the IBMers also recommended that the shortest task in your WBS should be 2 weeks, no less, otherwise you are micro-managing.)

Once you have a detailed plan for three months, and a high-level plan for the rest of the project, you can add more detail to further target dates as the project progresses, as each interim target is reached or on a rolling month-by-month basis. The level of change in any 3 month period will be manageable, much more than over the whole project.

There is a more recent corollary to the three month principle; the age of the mega-project should be over by now. Any IS project that takes many months or years to deliver the system is destined to fail. Yes, large systems are still needed, but break them into pieces that can be delivered, ideally about every 3 months; longer than that and you start to slide back to the mega-project approach, while shorter than that will not produce enough of the system to be worth delivering to the business. All business works in 3 month quarter cycles anyway, IT should too.

Cascade Day 12 - Principle #10: Models are better than text

David Wright — Tue, 03 Jun 2008 03:00:00 GMT

#10. Models are better than text.

I would like to think that by this point in time, this principle no longer requires justification. It has been at least a few years since I last saw a dense “SRD” or “SDD” document (SYSTEM REQUIREMENTS DOCUMENT, SYSTEM DESIGN DOCUMENT). I must offer my respect to the many talented people who labored to produce these documents over the decades; these documents were at least a step up from no Requirements or Design artifacts at all.

Consider what a ‘model’ really is in general; it is a representation of a finished product in a scaled down version; engineers have been literally creating models of what they are going to build for centuries, for such reasons as testing out problems on a small scale, and for presenting a view of the end result to whomever may be paying for it.

At this point, though, let us abandon any other aspect of physical engineering as an analogy for Information Systems development. Software is different; while tools and bridges and buildings have been created to either extend or protect the physical capabilities of human beings, Information Systems are created to extend the our mental capabilities, to help our thinking.

Given that, software can still be engineered, but it is a different type of Engineering. Software or Information Engineering has existed as a known concept since the 1970’s, although anyone who thought to call themselves a software engineer usually incurred the wrath, or at least disdain, of the established Engineering Disciplines and Schools. I am not an engineer, would not claim to be one, but my understanding is that traditional engineering is addressing software within its disciplines. In the future, as software becomes even more critical to our well-being and safety, it may be that those who design and create software will have to be accredited engineers, just like the ones who design and build bridges. I think history shows that quite a few early bridges and other structures were prone to collapse before engineering principles started to prevent it. Software is only a half-century old, so even in the age of internet speed and high change, more time will be needed to bring software in line with other long time products.

In the meantime, it should be a goal all of us in the IT business to adopt useful aspects of engineering to improve the quality of software, and modeling is a key concept to adopt. It almost frightens me that many still promote programming as an art form, that code can be beautiful or exquisite in some way. Well, even the most obscure art needs an audience to appreciate it, and it can’t just be other artists. Software is a product to be used, not admired, so if anything, programmers of the past 50 years have been more like craftsmen, using individual skills and experience to produce useful ‘objects’ for society to use. The problem is that demand continues to out-strip programmer output (remember the backlog!), so improved, repeatable and transferable methods are needed to transform software development from a craft to a true industry.

Cascade Day 11 - Principle #9: Leave a record of what you have done, so the project will not miss you if you leave

David Wright — Thu, 29 May 2008 06:22:00 GMT

#9. Leave a record of what you have done, so the project will not miss you if you leave.

If change is the only constant, then resources on a project will change. The risk in such change is that a person’s contribution to a project will be lost, and that the new person assigned to the project will have to start over. This is a particular risk in “quick and dirty” projects where an operating result is produced, but no one else can understand the code that was produced. However, if the contribution involves producing quality artifacts as described in principle #8, there is always a point-in-time record of what has been accomplished so far, which can be used by new project resources to continue the project with minimal disruption.

Cascade Day 10 - Principle #8: It’s the Deliverable (that matters), not the Task

David Wright — Wed, 28 May 2008 06:31:00 GMT

#8 --> It’s the Deliverable (that matters), not the Task.

The final deliverable is the Information System ready to be used effectively by the Business. If you can jump from ‘Start’ to this final deliverable in one “Task”, then power to you. Some people can do this; most cannot. This is again where a team of specialists is most effective on an average project.

This means that the project work will be divided into many tasks, sub-tasks, etc. . . . Once assigned a task, it is the goal of a specialist to produce a deliverable/result/artifact that can be used by the next specialist to further the progress of the overall project. Unfortunately, this simple idea has been the starting point for literally hundreds of IS delivery methodologies, many which spend an inordinate amount of content explaining how to do a task, how to amass all the tasks in Phases, and often insisting that its way is mandatory for success.

What this can lead to is an over-emphasis on the how of IT project tasks, to the detriment of actually completing them with all due speed. Here we see the task that is 90% done for weeks, or the infamous ‘analysis paralysis’ where a project cannot seem to get past Requirements. Ends do not justify any means, but Ends must be delivered.

Cascade Day 9 - Principle #7: One Architect/Analyst can generate enough work for two Developers and one Tester, structure your project teams in this ratio.

David Wright — Tue, 27 May 2008 06:13:00 GMT

#7 One Architect/Analyst can generate enough work for two Developers and one Tester, structure your project teams in this ratio.

This is actually one of those “rules of thumb” that have been borne out over time. (The ratio may vary a bit from case to case, like when the experience levels are different across the roles.) This ratio combines with the specialization of principle #6 to form the strong basis for the Cascade effect covered in the last principle to come.

I will be using the most common ‘role titles’ of analyst, designer, developer, and tester for the remainder of these blog posts. Sometimes these roles have different names, and there are many other roles in IT overall, but these four are the most recognizable to anyone doing primarily project work. (And the Project Manager makes five! Can’t forget them…)

Cascade Day 8 - Principle #6 - Specialize – each member of a team assigned to a project should do what they do best for the length of that project.

David Wright — Thu, 22 May 2008 05:21:00 GMT

This principle supports #5. With limited resources, there is another strong tendency to have IT staff ‘wear multiple hats’ on a project, especially the Business Analyst who is asked to also be the Project Manager and/or Lead Tester. Rather than getting more than you are paying for, you get less as an IT Staffer skilled in one role spends more time performing the other roles than an appropriate specialist would, and is distracted from being productive in their primary role.

At any time, and perhaps more so currently, there will be debates about which is better, a generalist or a specialist. I will agree that a strong, experienced generalist who can cover a wide number of tasks is the best resource you can have. However, these people are rare, and the odds of having even one such person in your average IT department are low . So, make sure that your staff is doing what they do best as much as possible as often as possible.

(This is not to say that people may not learn new roles over time, either switching to different roles or aspiring to be that coveted generalist. However, this is the task of overall resource management, overhead which will take up some portion of a person’s productive time. This is why most project management methods usually assume only about 6 out of each 8 hours can be used on actual projects. This reduced availability speaks even more to the value of specialization at a point in time. It also speaks to the value of matrix management, where Project Managers manage the projects and Resource Managers handle the ‘care and feeding’ of the valuable IT staff assigned to projects.)

Don't forget, come and see me at http://stores.lulu.com/dwwright99 .

Cascade Day 7 - Principle #4 - Pick the right project(s) for the business

David Wright — Wed, 21 May 2008 05:46:00 GMT

Principle #4 - Pick the right project(s) for the business.

At any one time, the IT department of an average company is running multiple projects. How did they get started? How were they even defined as a project that needed to be carried out?

No one may actually know. In more chaotic environments, projects can start as a seed of an idea, pick up momentum and resources if a manager or two can see that they will benefit from the project. At some point, the project will bump into another one, usually because they both want the same IT staff or other resources. Strong managers can often come out of these resource conflicts with what they need for their project, while the other managers suffer from their project going on hold or being cancelled. Otherwise, the conflict is escalated until one common, higher manager has to step in and decide who gets what; and this is often the first time the higher manager has even heard about the projects.

I sat in on a senior management committee meeting where the progress to date of a grand project was presented and a request for a budget increase was made to complete the project. The CEO took all this in, and commented that this was very interesting, but given the sizable amounts of money and time expended so far, why the heck had he never heard of this project before? The next week my manager sent me to see the CIO, who charged me with coming up with a new process for defining, approving, and controlling IT projects, better known these days as ‘Project Governance’.

So, how do you pick the ‘right’ IT projects? First you have to make the choice explicit, avoiding the random start-ups described above; do encourage any and everyone to suggest possible projects. An active strategic and operational planning process will also tend to drive out new projects as senior and middle management look for IT assistance to reach their assigned goals. All these proposed project ideas then become input to a ‘gating’ process, supported by means of valuing the worth of a project like, but not limited to, cost-benefit analyses.

Next time - Principle #5: Once a project is started, finish it.

Cascade - Day 6 - Principle #3: Use Architecture to describe the business, before and after projects.

David Wright — Tue, 20 May 2008 05:28:00 GMT

Principle #3: Use Architecture to describe the business, before and after projects.

“Architecture” is becoming a more widely used term associated with Information Technology. The number of adjectives applied to the term seems endless: “Technical Architecture”, “Systems Architecture”, “Business Systems Architecture”, “Enterprise Architecture”, and so on, so it must be important.

Why do we need Architecture?

Architecture is not an end in itself; Architecture exists because things need to be built.

Architecture is required when building anything that is not simple; in its essence, Architecture identifies all the separate components of an end product and how all the components are related and fit together to comprise the whole of the product.

Architecture is layered to capture and present information about the product to different audiences, from initial/high concept to detailed specification.

Applied to IT, a component assembly approach is dominating the industry, from the OO approach of software development, to real-time use of defined services, as popularized by SOA. Specialized agent software is starting to assist in finding services and brokering between different services to perform transactions collaboratively.

For the average company using IT, architecture is needed because it needs focused IT functionality to deliver the highest current value, while trying hard to ensure that the function will work (“integrate”) with the next function that is needed.

It should be emphasized that this is Architecture for Information Systems.; there are methods and approaches being promoted for an overall “Business Architecture”, architecture for the whole business, not just IT. Originating from IT circles, they often look like an IT/IS architecture, which can be confusing. The Architecture in this book is definitely about Information Technology and Systems.

The good news is that you do not need to invent an IT Architecture method for your company. Many authors and vendors have methods available already. When starting out, I recommend investigating/adopting the architecture that started it all, the “Zachman Framework” as developed and enhanced by John Zachman. He devised a matrix framework that cross-references core information concepts against the levels of abstraction that are used by different audiences and participants in delivery of Information Systems. See www.zifa.com ...

The key benefit of the framework is that it illustrates how information concepts can be transformed through the levels to produce operating components of the needed Information Systems.

Last two points on Zachman:

- The cross points of the Concept columns and Abstraction rows are called “Cells”; each cell will group the methods or documents (artifacts) that describe the content of the cell. Zachman does not specify what artifacts to use, or what methodologies to use to create the artifacts. The things in each cell on the diagram are just suggestions.
Keep this in mind for Principle #10.

- The Framework looks two-dimensional, but it is actually multi-dimensional when artifacts in one cell are cross-referenced to artifacts in other cells, the most obvious example is What vs. How, i.e., what function creates specific occurrences of data.

Remember, be sure to visit my bookstore at http://stores.lulu.com/dwwright99

Cascade - Day 5 - Principle #2: Projects change the business, so know the overall business first

David Wright — Fri, 16 May 2008 05:15:00 GMT

Principle #2: Projects change the business, so know the overall business first

A never-ending discussion in IT circles is about how much IT staff need to know about the business that the information systems are supporting. It is high-lighted by every want-ad for an IT job that says previous experience in the employer’s industry is mandatory.

Is detailed industry knowledge and experience absolutely necessary for an IT job? No.

Can an IT staffer be effective with absolutely no knowledge of their employer’s industry? No.

As in many situations like this, the ‘Yes’ answer lies somewhere between the two extremes. Like a pendulum, the level of industry knowledge will vary across this spectrum, based on the specific organization, and by the particular IT role; e.g. Analysts need to know more than Programmers, and it justifiably argued that Testers need to know even more than Analysts.

So, some industry knowledge is required. I suggest from experience, however. that several week’s research on an industry is equivalent to several year’s work experience, as much of a person’s experience is rendered out-of-date by industry changes, or is too specific to the company they worked at. This is more true today than ever, as the ubiquitous Web makes information about almost anything available with a text string and few mouse clicks.

As a result, IT needs to know something about the business going into a project, and the willingness to learn more as a project progresses.

The addendum to this discussion, however, is how much does IT need to know about the specific way their employer conducts business when competing in their industry . Again from experience, I suggest that very little or no such knowledge is needed going into a project. The cliché that “a little knowledge is a dangerous thing” applies here. If IT people know too much about the current business, they may be unconsciously constrained when devising new IT solutions by ‘the way things have always been done here.’ In extreme cases, this can lead to an IT staffer having the delusional belief that they know more about the business than the systems users and their management.

Do not fall victim to this belief. IT is about underlying hardware and infrastructure, and the information systems that run on them. The systems’ users and their management --- supported by all the strategies, policies, procedures and rules that define and control the business --- will know the specifics of their business better than IT; their jobs depend on it.

This is not to imply that all business users & management are omniscient, or that the all business’s operate without duplications or errors, or that there are not things the business doesn’t know yet. In fact, effective use of IT can address many such issues in the operation of a business, but IT and IT people do this in support of the business; IT does not define the business.

So, know your business in order to support your business.

Cascade - Day 4 - Principle # 1: There is always more work to be done than people to do it.

David Wright — Thu, 15 May 2008 04:52:00 GMT

Let’s look briefly at what each principle means or implies; which will serve as introductions to subsequent posts that will cover the principles in more detail.

#1. There is always more work to be done than people to do it.

Bordering on glibness, this principle summarizes the reality of virtually all organizations and activities, not just Information Systems delivery. It implies that a group within an organization charged with delivery of end results will a have a back-log of work not yet done. The existence of such a back-log is in itself not a problem, it reflects the desire of an organization to solve new problems and proactively improve itself; the problem arises when it grows perceptively in size from management’s perspective, and the length of time a change item sits on the back-log increases such that it can be measured in numbers of months or years.

So, we must accept that there will be a backlog; fully eliminating it would mean that the delivery group (like IT) becomes redundant, or that the overall organization has stagnated. What must be done is to embrace the back-log; it is IT’s input material and should be managed as such.

Next time: Principle #2 - Projects change the business, so know the overall business first.

Cascade - Day 3 - Principles

David Wright — Wed, 14 May 2008 04:33:00 GMT

Like you, I have read my fair share of IT books and blogs, and each author has to decide how to best present what they are trying to communicate. One way is to describe the problems/opportunities of interest to the reader, then document the new approach or method that solves the problems, etc.; the reverse is to document the new approach/method first and then describe what problems it fixes, etc.

I would like to try a mixture of the two, in the context of a set of Principles that I think will put all the content of what I am going to write context. This is not an original idea, I must admit, as many manifestos and proclamations have been used to introduce new ways of things; the Agile Manifesto is well known, and I am a particular fan of the Business Rules Manifesto. These and others like them lay out the basic reasons for their existence and the value they provide.

Principles can be very effective; the best I have ever seen were created by Mao Tse-tung for the new Chinese Red Army after his first insurrection failed. His principals for protracted/attrition warfare were summed up in a sixteen character military guide that even an illiterate peasant could understand…

"Enemy advances, we retreat.
Enemy halts, we harass.
Enemy tires, we attack.
Enemy retreats, we pursue."

Effective words, against which I hope my own do not completetly whither in comparison.

So what are these new IT principles I propose?

1- There is always more work to be done than people to do it.

2- Projects change the business, so know the overall business first.

3- Use an overall Architecture to describe the business, before and after projects.

4- Pick the right project(s) for the business.

5- Once a project is started, finish it.

6- Specialize: each member of a team assigned to a project should do what they do best for the length of that project.

7- One Architect/Analyst can generate enough work for two Developers and one Tester, structure your project teams in this ratio.

8- It’s the Deliverable (that matters), not the Task.

9- Leave a record of what you have done, so the project will not miss you if you leave.

10- Models are better than text.

11- Partition large projects into 3 month phases, which is the longest period you can plan for without the chance of significant change to priorities, resourcing, etc.

12- Within the three month phase, parcel work into two-week periods; analyze for 2 weeks, then design and develop for 2 weeks ( 2 developers ), and then test for 2 weeks. When the first 2 weeks of analysis is done, start the next two weeks of analysis in parallel to the design/development, carry on in cascading 2 week periods until all of the project scope has been addressed.

13- Given many medium to small software Deliverables, use architecture to manage and integrate the Deliverables into a complete system.

I consider these a work in progress so, like most inventors of new principles or practices, I have come up with an overall name to encompass them, for now and as they evolve. It is:

Next time, I will start to provide details on each Principle, starting (of course) with #1.

Cacscade - Day 2 - what can you do to be successful?

David Wright — Sat, 10 May 2008 03:53:00 GMT

The premise of these blog entries is that the situation described in the previous post can change, but it is usually slow-going; or worse, there can be an immediate channge when your department is outsourced; it happens. In the meantime, what can be done to be “successful” in your average IT department in your average company?

What has to be done is to deliver on all those change requests, and finish those current projects so you can start new ones (there will always be new ones). At risk of sounding like a psychedelic poster, this means accepting the things you can’t change and changing the things you can.

What can’t you change right now:

The installed base of legacy systems.

The backlog of change requests and bugs (even if you do manage to deal with a lot of these things, there will be new ones come along to take their place; that is job security).

Senior management’s’ conflicting priorities for IT.

What can you change (or at least start to change?)

The structuring and management of the IT projects.

Overall management of staff by skills/specialties.

Allocation of staff to the projects.

What will follow in this blog is my prescription for this change, supported by some war stories, lessons learned, and lots of ideas to try. Even an ‘average’ company has some unique aspects, so maybe not everything in this book will work for everyone, but I hope to give you enough that some will work. My own fervent belief is that visible success with IT projects may lead to softening/improvement of the things you can’t change right now.

And why should you believe me?

David Wright is a veteran of over 25 years in the IT trenches. He started as a programmer in the mainframe-dominated 80’s, followed by 20 years as a Business Analyst and Architect, supplemented with stints in project management and testing when limited resources required it.

Mr. Wright has spent time both in operational areas delivering enhanced and new business systems, and in research and development focusing on information system methodologies and tools. The companies he has served in these capacities have ranged from life insurance to express delivery to equipment leasing & financing. In those companies, he has supported both the operational business’ and supporting functions like Finance, Human Resources, and even IT administration systems.

Sound good enough? If so, lets get started.

Next time: Start with some Principles...

Cacscade - Day 1 - does this sound like where you work?

David Wright — Fri, 09 May 2008 03:42:00 GMT

Day 1:

I have recently made a major career change, moving from what I would now call a client company to a consulting company. It's an exciting change, but I don't expect to write about my new experiences at this time.

However, I had also been spending some time writing an extended piece about my experiences over the years working in several IT departments, especially to define a set of "better practices" for succeeding in a multi-project environment. (I read another blogger's point that claiming you have a "best" practice is the height of egotism, and it rang true to me, so I will stick with "better".)

This material appeared on a more general blog of mine, and out of it evolved "Cascade". It is not strictly about Business Analysis, but we do not work in a BA vacuum, we are always part of a team to deliver a product or service, and I can think of no better analogy than fast flowing water that swirls around rocks and other obstacles and emerages to fill a large body of water, a Cascade of information system deliverables that add to the overall portfolio of a company.

You can see the resulting book at http://www.lulu.com/content/2088656 , and read the first few pages. What I plan to do in this blog is feature the material from the forward/introduction (hopefully to pique your interest in reading the rest!).

First up: Does this sound like where you work?

The book was written for people who work at companies that have an IT department to support their non-IT business. In comparison, this blog is not written for people who work at IT companies; from Google on down to someone selling excel macros. The main reason is that I have not worked for an IT company and, although I have worked with many in customer-vendor relationships, I do not feel qualified to write about something I do not have experience with. However, even companies selling IT need some other IT to help run their business, so perhaps some of my experiences may overlap with theirs.

Given that, let us consider the vast majority of companies that are making automobiles or serving hamburgers or providing investment advice or any and everything else. In those companies you will find a department/division filled with IT ‘professionals’: Programmers, Project Managers, Analysts, Testers, Implementers, Operators, and loads of other specialists like Database Administrators and Network Engineers. (I use professional in quotes because long-standing professions like lawyers and engineers like to protect the use of the word.)

The name of this group has evolved generally to the ‘Information Technology Department’, or IT for short (no ‘D’ at the end); such past names as “Data Processing” or “Management Information Systems” seem to have faded away . As an acronym, “IT” is used interchangeably to name the department and describe the functional scope addressed by that department.

So, as we speed through the first decade of the 21st century and on into the next, what is the common situation that these IT departments face?

 It probably includes an installed set of information systems that are used by the business to control and report on its operations. There is always more than just one system, and possibly hundreds(thousands?), many doing the same work as many others. Some may be decades-old, a few may be recent and using fairly new technologies, with the implementations of the rest spread-out over the history of the department since that first ‘computing machine’ was purchased, with the wide range of development and operating technologies which that implies. (How along ago did you read that your mainframe computer was dead? Did it die? Not likely.) The still favourite term for describing this installed base is legacy systems.

 It probably includes a large back-log of requested changes to that installed base of systems, overlaid with a long list of problems/bugs in the systems that the business is currently ‘working around’ until they ever get fixed.

 It probably has an “IT Strategy” that describes in glowing terms how the above two cases will be remedied by moving to some new method or tool or one enterprise system… if the budget and resources can ever be freed up from fixing and changing the current systems.

 It is probably overseen by a senior management group (or steering committee or review board) that is charged with deciding what IT work is approved and carried out. This group may be formal or informal, and may only be one person in the end, the CEO or someone he/she has delegated it to; since IT costs money, the CFO is a common choice.
I n this structure, the head of the IT department (CIO is the hot title, of course) plays a committee secretary and/or facilitator role, who is supposed to assist the rest of management in making their IT choices. This is a difficult role, as the rest of management has a split-view of IT, that most of it is a waste of time and money, except for the work each one wants for their own department/division.

 There are probably a large number of current projects being carried out, that no one can remember when they started and, even if some target date has been set, no reasonable expectation exists that they will end soon.

 It is staffed by a group of IT staff that has remained the same size in numbers, or has been reduced, while being charged with doing more work than ever: “Work Smart, Not Hard”., “Do More With Less”. Each person is probably assigned to many of those current projects, juggling the work and trying to determine what they should really be working on.
The overall morale and effectiveness of this staff depends greatly on the skills of their immediate management and more senior managers who provide some level of inspiration; if not, morale plunges and turnover increases.

Sound familiar? Then you have the same experiences as me, and I will be writing more entries for you.

Next time: what you can't change but, more importantly, what you can change...

Cascade - The Book

David Wright — Thu, 08 May 2008 02:55:00 GMT

This blog has been started because, like anyone who writes a bit for a living, I thought I had a book to write...so I did.

This blog also hi-lights the arrival of lulu.com, a website that will publish your book with the 'tarnish' of a vanity presss.

So, check both out at http://www.lulu.com/content/2088656 . The book is "Cascade - Better practices for effective delivery of information systems in a multi-project environment. "

Future posts will feature selections from the book, starting with the forward/introduction, so come back tomorrow!

David Wright